The task of accommodating increasing bus traffic in data communication networks continues to pose as a challenge. The primary bottle-neck in most data communication networks appears to be the system bus. The system bus is a bottle-neck primarily because many devices share the same bus and must contend for its use in transmitting or receiving data. For, this reason, the system bus may be unavailable at crucial times for reasons such as operating priorities, system interrupts, and other bus traffic. Thus, in a computer system, it is necessary to buffer data received to accommodate bus traffic with other data devices.
Examples of devices buffering data received to accommodate bus traffic with other data sources and sinks include data conversion devices. Data conversion devices are basically front end communications processors that act as the interface between the host CPU and external terminals. Data conversions devices provide limited internal storage to continue receiving data from data sources while waiting for converted data to be moved to data sinks via the system bus.
Since the prior art solution is to provide storage capability while the system bus is busy, there exists an inherent problem in the prior art solution. This problem manifests when the period during which the system bus remains busy is long enough so that the amount of data accumulated in the temporary storage exceeds its storing capacity. When that occurs, data may be lost. To prevent data loss, data must be transferred to another location.
Generally, the data transport techniques most commonly used are Programmed I/O and Direct Memory Access (DMA). With Programmed I/O, the Host CPU is involved in every aspect of the data transport process. Even if the network adapter's control and data port parameters are defined and mapped in system memory, the performance of the network/system interface is, in most cases, limited by the CPU's input/output bandwidth and system bus utilization. Moreover, because Programmed I/O utilizes the CPU in every aspect of transferring data, when used as the transport mechanism in preventing data loss due to other bus traffic, this technique or those using the Host CPU as the main driving force in the data transport process is subject to an additional possibility of data loss when CPU interrupt latency rises due to CPU workload.
Direct Memory Access (DMA), on the other hand, is designed to transfer large "blocks or units of data" with little or no Host CPU intervention. Most DMA transport mechanisms are based on the Master-Slave transport model. With this type of transport mechanism, the Host CPU initiates the data move or transfer, and once started, the Host CPU is not involved again until the entire "block or unit of data" has been transferred. For this reason, DMA is much more efficient in term of CPU time required and is a preferred method to transfer large blocks of data than Programmed I/O or other CPU-intensive data transfer methods on the whole. On the other hand, DMA data transfer is slower than Programmed I/O and other CPU-intensive data transfer methods due to the extra moving steps involved in DMA transfer. Moreover, DMA techniques, such as DMA masters and DMA slaves, have their limitation in that additional processing is normally required to move data from where the DMA process puts it to the data sink (e.g., a specified application memory location). This is because the DMA controller is not able to determine the type and size of data, and the CPU must examine the data to determine the proper data sink.
For the above reasons, in devising a data transport technique to use in moving data from the temporary storage buffer to another location, a dual approach, which utilizes non-DMA data transfer (e.g., Programmed I/O) to move data to the proper sink in most instances but switches to DMA transfer if the internal storage limit is approached (i.e., when the host CPU is slow due to higher priority tasks), is most desirable.
The structure and operation of the auto-DMA mechanism that provides switching from a non-DMA mode to a DMA mode are disclosed in more detail in co-pending application Ser. No. 08/343,073, entitled "NETWORK CONTROLLER HAVING AUTOMATICALLY INVOKED DMA DATA TRANSFER," to Peter Ecclesine, filed concurrently herewith and incorporated herein by reference. However, when the host CPU is again available to process received data, it is desirable to provide switching back from the DMA mode of operation to the non-DMA mode as soon as possible.
Also, it is desirable to provide a DMA-to-non-DMA switching mechanism that keeps the data in the proper sequence since switching may cause the order of the data to be processed out of its intended sequence.